Comprendre les écarts entre Metric et OSRM
Philéas Condemine
2019-07-22
Introduction
Ce document est rédigé avec 3 objectifs :
- Comparer sur un plan méthodologique les distanciers OSRM et Metric
- Analyser les différentes pratiques entre OSRM et Metric, en particulier les différences de résultats et leurs conséquences possibles.
- Identifier des pistes d’amélioration pour contribuer à développer OSRM afin qu’il remplisse entièrement les besoins des SSM/SSP.
A propos du calcul de trajets
On souhaite comparer les résultats de deux outils de calcul d’itinéraires (distanciers) : OSRM et Metric.
Metric est un outil développé par l’INSEE depuis des années. A la DREES, des calculs de distances doivent être réalisés pour des millions ou des milliards de paires et l’outil Metric est utilisé depuis plusieurs années.
Par exemple : 36k communes => 1 milliard de paires de trajets asymétriques.
Les fichiers précalculés de distances de centre communal à centre communal fournis avec l’outil ne sont pas suffisants, par exemple on souhaite connaître le temps d’accès à une maternité en utilisant la position précise de l’établissement. Bien sûr on trouve des astuces pour ne pas calculer les 36k x 500 trajets. On commence par un calcul à vol d’oiseau pour retenir les 3-5 plus proches maternités de chaque commune puis on calcule les 100-200k trajets. Ces calculs se comptent en heures avec l’outil Metric. Nous avons donc souhaité tester l’outil OSRM qui est très connu pour cet usage.
D’autant qu’OSRM a une licence bien plus ouverte que Metric, ce qui rend les travaux fondés sur OSRM plus facilement reproductibles.
Les calculs avec OSRM sont très rapides, mais les requêtes avec le serveur de calcul router.project-osrm.org sont limitées en nombre, nous avons donc déployé une instance locale sur une machine virtuelle fournie par la DSI des ministères sociaux.
L’outil Metric est enrichi de fonctionnalités de cartographie, de manière similaire, une package R (nommé osrm) a été développé par des chercheurs du CNRS https://github.com/rCarto/osrm proposant également la cartographie d’isochrones, ainsi que des trajets avec étapes.
Pour ces deux outils, on fait l’hypothèse que l’usager roule toujours à la vitesse limite, et pour ajuster la vitesse de conduite on modifie virtuellement la vitesse limite.
Metric
Les calculs de trajets de commune à commune s’appuient sur les routes IGN-BDTOPO d’importance 1 à 4 et excluent donc les routes d’importance 5 (desserte locale infra-communale), contrairement au calcul de trajets en infra-communal.
Ceci pourrait conduire à une sur-estimation du temps de trajet pour des communes adjacentes.
Les trajets de commune à commune sont les trajets qui relient les chefs lieux des communes.
Vitesse par segment de route
Ajustement des vitesses limites selon les routes et les densités de population dans les carreaux en utilisant 3 tranches :
- <500 habitants/km² (pas d’ajustement)
- [500-4000] habitants/km²
- >4000 habitants/km²
| Moins de 500 hab/km² | Entre 500 et 4000 hab/km² | Plus de 4000 hab/km² | |
|---|---|---|---|
| Autoroute HC | 120 | 100 | 60 |
| Autoroute HP | 120 | 100 * 0,8=80 | 60*0,6=36 |
| Quasi-autoroute HC | 100 | 90 | 40 |
| Quasi-autoroute HP | 100 | 72 | 24 |
| Route à 2 chaussées HC | 90 * sinuosité - 0,1 * pente² | max(60 * sinuosité - 0,1 pente² , 15) | max(30 * sinuosité - 0,1 * pente², 15) |
| Route à 2 chaussées HP | 90 * sinuosité - 0,1 * pente² | 0,8 * max(60 * sinuosité - 0,1 pente² , 15) | 0,6 * max(30 * sinuosité - 0,1 * pente², 15) |
| Route à 1 chaussée HC | max(65 * sinuosité - 0,1 * pente², 15) | max(40 * sinuosité - 0,1 pente², 15) | max(20 * sinuosité - 0,1 * pente², 15) |
| Route à 1 chaussée HP | max(65 * sinuosité - 0,1 * pente², 15) | 0,8 * max(40 * sinuosité - 0,1 pente², 15) | 0,6 * max(20 * sinuosité - 0,1 * pente², 15) |
| Route empierrée HC/HP | 20 | 20 | 20 |
| Chemin HC/HP | 20 | 20 | 20 |
| Bac auto HC/HP | 13 | 13 | 13 |
| Bretelle HC/HP | 60 | 60 | 60 |
OSRM
La méthodologie qui permet de préparer les données et réduire l’information pour accélérer les calculs à la volée est décrite ici 
Comparaison pratique OSRM - Metric
| Metric | OSRM | |
|---|---|---|
| Graphe utilisé | Graphe construit à partir de la BD topo de l’IGN, millésimé 2012. Mise à jour possible mais coûteuse en temps. | OpenStreetMap (base de données collaborative, mise à jour en continu) |
| Exhaustivité du graphe | Graphe plutôt ancien, datant de 2012 | Variable selon le territoire. Exhaustivité et qualité plus élevées en milieu urbain |
| Trafic (heure pleine) | Vitesse théorique, calculs en heures creuses et en heures pleines. Application d’un coefficient réducteur des vitesses limites selon la densité de population dans le carreau. | Par défaut, non, mais Possibilité de définir un fichier de profil car.lua ad-hoc avec des vitesses limites par type de route et pénalités/interdictions d’accès spécifiques par type de route, très facile à paramétrer. Possibilité d’intégrer des données de trafic, cf serveur de démo et la doc sous la forme de pondération des arêtes. On pourrait reproduire la méthodologie Metric, mais aussi en développer d’autres avec des données de trafic réelles. |
| Mode de déplacement | Voiture, transport en commun pour Paris, Lyon, Marseille, Loire | Voiture, piéton, vélo + profil ad-hoc (camions, heures-pleines…) |
| Traitements réalisables | Calcul de la distance et du temps d’accès entre deux points, calcul de la distance et du temps d’accès à l’équipement le plus proche | Calcul de matrices de distance origine/destination, calcul d’isochrones, calcul d’itinéraires |
| Cartographie | Cartographie des carreaux de 200 mètres selon leur temps d’accès à l’équipement le plus proche | Calcul d’isochrones et calcul d’itinéraires avec le package R osrm. |
| Symétrie du graph | Symétrique | Asymétrique (prise en compte des sens uniques et potentiellement du rôle asymétrique des pentes si l’altitude est ajoutée) |
| Contraintes | Traitement réalisé de commune à commune à l’échelle métropolitaine ou entre des coordonnées précises mais à une échelle départementale | Paramétrages supplémentaires lors de l’installation pour tenir compte de l’altimétrie, du trafic routier… |
| Limites | Temps de traitement parfois très long | Installation d’une instance en propre nécessaire pour les traitements de masse |
| Installation | Non concerné pour l’Insee, Installation à partir d’une clé USB fournie pour les SSM | Compétences pour installer et paramétrer l’instance OSRM, coûteux en temps. Une communauté importante est disponible pour trouver de l’aide, résoudre des erreurs, apporter des améliorations. |
| Paramétrage | Paramétrage des données p.e. les arêtes mais coûteux en temps et non-documenté | Définition de fichier de profil et pondération des arêtes avec des données de trafic. |
| Prise en main | Aisée, interface presse-bouton. | Utilisation d’API ie utilisation d’un langage de programmation Python/R/JavaScript, etc. même faisable en SAS. Connaissance de base quant à l’utilisation de données géographiques pour manipuler des géo-coordonnées, utiliser le bon référentiel de projection. |
| Temps de calcul | 100 fois plus rapide |
Comparaison méthodologique OSRM - Metric
| Metric | OSRM | |
|---|---|---|
| Virage | Sinuosité = \(\frac{Distance\ à\ vol\ d'oiseau}{distance\ routière}\) | Pénalisation avec l’angle réel : \(turn_{duration} =traffic.light_{penalty} + \frac{turn_{penalty}}{1 + \exp^{-\frac{13}{turn_{bias}} \times \frac{turn_{angle}}{180} - 6.5*turn_{bias}}}\) |
| Ajustements sur la vitesse limite | Prise en compte de la densité de population au carreau | Définitions modifiale car.lua pour chaque type de route et selon le matériau/texture : herbe, pavement, tartan, goudron… |
| Prise en compte de la pente/altimétrie (elevation) | gradient d’altitude | Par défaut, non ! Il faut paramétrer l’installation et en particulier dans le profile.lua, la fonction setup, process_segment en intégrant des données d’altimétrie IGN par exemple, attention au référentiel de coordonnées.ajout en 2014, voici un exemple de mise en oeuvre en Suède |
| Ajustement à la signalisation | Aucun | Par défaut, toute signalisation feu tricolore et stop, sous forme de pénalité de X secondes. X est modifiable pourrait servir de proxy pour tenir compte du temps passé au feu pendant les heures de pointe. En outre, paramétrage possible pour ajouter passage piéton selon dispo dans OSM. |
Distribution des écarts
Les calculs s’appuient sur des données différentes et des algorithmes différents, il est donc naturel que les résultats diffèrent.
Pour quantifier ces écarts, on utilise un jeu de données qui contient - En observation : des couples de communes représentant une commune de résidence d’un groupe de patient et une commune d’hospitalisation de ces patients - En variables : - Le flux de patient de la commune de résidence vers l’établissement - Le temps de trajet (HP = heure pleine, HC = heure creuse) et la distance (KM) calculés par OSRM et Metric - La population de la commune de résidence des patients - L’altitude moyenne de la commune de résidence des patients
Ecart temps - distance
## HC HP KM Temps_OSRM KM_OSRM
## Min. 1.00000 1.00000 0.30000 0.40000 0.27500
## 1st Qu. 36.00000 42.00000 35.30000 33.80000 34.12300
## Median 55.00000 62.00000 62.20000 53.40000 60.18700
## Mean 60.25944 67.34876 73.41027 59.24176 70.95406
## 3rd Qu. 80.00000 89.00000 103.60000 80.40000 99.80400
## Max. 199.00000 231.00000 199.90000 188.10000 199.99900Sur de courtes distances, Metric surestime le temps de trajet par rapport à OSRM.
C’est peut-être parce que Metric ne tient pas compte des routes les plus petites (niveau 5 IGN BDTOPO) pour les trajets intercommunaux.
Lorsque les distances augmentent on remarque surtout une plus grande variance sur les temps de trajet estimés par Metric par rapport à ceux estimés par OSRM pour lesquels le lien temps / kilométrage est plus fort : R² 87% HC, 83% HP vs 94% OSRM.
## [1] 0.8676506## [1] 0.829217## [1] 0.94475Ecart temps - altitude
contours <- rgdal::readOGR("../external_data/GEOFLA_2-2_COMMUNE_SHP_LAMB93_FXX_2016-06-28/GEOFLA/1_DONNEES_LIVRAISON_2016-06-00236/GEOFLA_2-2_SHP_LAMB93_FR-ED161/COMMUNE","COMMUNE")
infos_geo <- contours@data
infos_geo <- infos_geo %>%
select(INSEE_COM,Z_MOYEN,POPULATION)%>%
mutate(POPULATION=as.numeric(as.character(POPULATION)),
INSEE_COM=as.character(INSEE_COM))
save(infos_geo,file = "contours.RData")## Z_MOYEN POPULATION
## Min. 1.000 0.000
## 1st Qu. 104.000 197.000
## Median 187.000 442.000
## Mean 278.313 1779.369
## 3rd Qu. 335.000 1099.750
## Max. 2727.000 458298.000On peut lire les paires pour une altitude donnée (points sur la même ligne verticale), plus l’altitude est élevée, plus Metric sur-estime le temps de trajet par rapport à OSRM. C’est normal, Metric tient compte de l’altitude et pénalise la vitesse en montagne par la pente alors qu’OSRM n’en tient pas compte dans sa configuration par défaut.
Ecart temps - population
Proportion de communes à moins de X minutes
Pour mesurer l’impact du changement d’outil, on s’intéresse à un problème simple utilisé dans le calcul de certains scores : le nombre d’établissement (resp. de professionnels) situés à moins de X minutes.
Il ressort visuellement que les mesures d’accessibilité sont souvent plus optimistes avec OSRM. De plus, lorsque l’accessibilité calculée avec OSRM est plus forte qu’avec Metric, elle l’est beaucoup plus que lorsque c’est Metric qui donne le meilleur niveau d’accessibilité (asymétrie).
Cohérence temps - flux de patient
Sur l’ensemble des données, le lien entre temps d’accès aux soins et part de patientèle est plus cohérent avec les données OSRM qu’avec les données Metric : R² OSRM = 94% vs Metric = 92%.
## [1] 0.9424593## [1] 0.9244437## [1] 0.9230287OSRM ne tient pas compte des données d’altimétrie, on s’attend donc à ce que les temps d’accès calculés avec Metric soient davantage en adéquation avec la distribution des patients, mais on obtient (pour les communes à plus de 300m d’altitude) un R² identique avec les deux méthodes : 96%. Ici c’est l’argument du temps de calcul qui permet de départager OSRM et Metric. De plus il faut garder en tête qu’il est possible de paramétrer le serveur OSRM pour tenir compte de l’altimétrie.
## [1] 0.9638731## [1] 0.9618628Score de type APL
Un risque avec le changement de méthodologie est la modification des scores et donc de certaines politiques telles que le zonage des communes en “zone d’intervention prioritaire”, “zone d’aide complémentaire” ou “zone de vigilance”. Le premier niveau étant appliqué automatiquement lorsque l’accessibilité potentielle localisée est inférieure à 2. Si brutalement certains scores varient de +/- 1 ou même +/- .2 les conséquences pourraient être importantes.
Le calcul de l’APL est complexe
Pour réaliser rapidement une mesure d’impact du passage Metric - OSRM, nous calculons un score plus simple :
offre (séjours disponibles en établissements) / demande (population dans la commune) pondéré par la distance avec un noyau exponentiel (transformation 1/exp(.)).
\(\frac{Offre\ hospitalière}{Demande\ des\ patients}* exp^{-\frac{temps\ d'accès}{20\ minutes}}\)
Les éventuelles dégradations seront faibles mais à l’inverse certaines amélioration du score seront très marquées.
## Min. 1st Qu. Median Mean 3rd Qu. Max.
## 0.00002 0.86248 1.83999 3.21379 3.79892 104.67266
